In packet telephony or Voice over Internet Protocol (VoIP) networks, there are several protocol stacks that have been defined to facilitate the provision of voice, video and other messaging services. These protocol stacks include H.323, Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP) and others.
H.323 is a standardized communication protocol that enables dissimilar devices to communicate with each other using a common set of codecs, call setup and negotiating procedures, and basic data transport methods.
The MGCP protocol, defined under Informational RFC 3435 (F. Andreasen, B. Foster, “Media Gateway Control Protocol (MGCP) Version 1.0”, RFC 3435, January 2003), incorporated herein in its entirety, is suited for centralized systems controlling IP telephony gateways that operate with endpoints having little or no intelligence, such as analog telephones. MGCP is a plain-text, master/slave protocol that allows call control devices, also referred to as call agents, media gateway controllers or more generally as servers, to take control of a specific port on a gateway or on an MGCP-controlled IP phone, also referred to more generally as a client or MGCP endpoint. MGCP messages between call agents and MGCP endpoints are sent with Internet Protocol over User Datagram Protocol (IP/UDP). No voice data is transmitted through the MGCP protocol itself. Rather, all the voice data transfer occurs directly between the gateways.
PacketCable is an industry-wide initiative for developing interoperability standards for multimedia services over cable facilities using packet technology. PacketCable developed protocols called Network-based Call Signaling (NCS) and Trunking Gateway Control Protocol (TGCP), which both contain extensions and modifications to MGCP while preserving basic MGCP architecture and constructs. NCS is designed for use with analog, single or multi-line user equipment on residential gateways, while TGCP is intended for use in VoIP-to-PSTN trunking gateways in a cable environment. Hereinafter, references to MGCP are defined to include NCS/TGCP unless otherwise noted.
The media gateway collects events (e.g., on-hook, off-hook, flash-hook, digit input) in a quarantine buffer according to a list of requested events communicated to the gateway by the media gateway controller using a NotificationRequest (RQNT) command. After notifying a list of events to the media gateway controller, the gateway awaits a response, and possibly a new request for event collection from the media gateway controller. Once the response, and possibly a new event collection request, has been received by the gateway, the events in the quarantine buffer are processed first, followed by any other events that may occur subsequently.
During periods of network congestion, media gateway controller overload, loss of connectivity to the media gateway controller, or other interruptions in the communication between gateway and media gateway controller, it is possible for the quarantine buffer to collect a large number of events. Several of these events may contain real-time state information that may not be of interest at a later time. However, due to the first-in-first-out nature of the quarantine buffer, currently defined mechanisms only allow either all buffered events to be processed (in order) or all buffered events to be discarded.
Consider the example of a gateway connected to a telephone where the user picks up the handset and expects to hear a dial tone. In a scenario in which there is network congestion, media gateway controller overload, or loss of network connectivity, the user may not hear dial tone and consequently will hang up the handset. This user activity generates both an off-hook and an on-hook. Since the user did not hear dial tone, the user may repeat the sequence. When the media gateway controller regains connectivity with the gateway, first-in-first-out processing of such “stale” events likely will lead to undesirable behavior and further delays, e.g., dial tone being turned on and off repeatedly to the user.
As noted above, the currently defined mechanisms for handling this problem are crude inasmuch as they only allow for either clearing or processing the entire quarantine buffer. One difficulty with the known approach is that the media gateway controller may not realize that the gateway has collected events which for all practical purposes are stale, and hence it does not know to ask the gateway to discard such events. Another difficulty is that in cases where the media gateway controller has reason to suspect that the gateway may have stale events in the quarantine buffer, it can instruct the gateway to discard all events, but in so doing, events that are not stale may also be discarded.